«Точка-точка», брокер, ESB: какие интеграции помогут построить слабо связанную ИТ-архитектуру

Слабая связанность→ — основа гибкой ИТ-инфраструктуры. При этом сам факт наличия интеграций в контуре – не индикатор монолита или его отсутствия. Главное — как эти интеграции реализованы. Один способ может привести к нагромождению сложно поддерживаемых связей и как результат — сложному масштабированию бизнеса. Другой – к контуру, который можно быстро менять и дорабатывать на ходу. В этой статье расскажем, как подходы к интеграции влияют на связанность и какой способ выбрать, чтобы контур компании был слабо связанным.

Мы уже ранее касались подходов к интеграциям в одной из наших статей→, сегодня посмотрим на эту тему именно с позиции выстраивания слабо связанной архитектуры и гибкости бизнеса.

Как выглядит слабосвязанная архитектура с эффективными интеграциями?

Перед выбором подхода или инструмента стоит задать бенчмарк и посмотреть, как все должно работать в идеале. Ниже – пять главных критериев идеального состояния интеграций:

1. любую интеграцию/сервис в контуре можно легко и быстро доработать, и это никак не скажется на работе контура;
2. такая интеграция выдерживает пиковые нагрузки и работает без задержек;
3. новый поток данных можно запустить без доработки сервисов;
4. ошибка в одном сервисе не вызывает проблем в других;
5. легко осуществлять мониторинг, его можно делегировать техподдержке (вместо команды разработки).

Эффективность интеграции зависит от связей между компонентами. Рассмотрим ключевые составляющие.

Основные компоненты любой интеграции

Вне зависимости от типа интеграции, в любой из них есть:

• система-источник;
• система — получатель информации
• ETL-слой (extract, transform, load – извлечение, преобразование и загрузка)
• хранилище данных — пространство, в которое записывается переданная информация.

Этот список не отражает нюансы и логику каждой конкретной интеграции. Но он точно облегчит понимание сути плюсов и минусов каждого из подходов, так как свойства конкретной интеграции зависят от того, где (относительно систем) находятся ETL-функции и хранилище.

«Точка–точка»

Самый простой и понятный тип интеграции. И именно он чаще всего характеризует монолитные системы.

Представьте: есть один сервис, есть второй сервис и они обмениваются информацией через прямые интеграции между собой. Таких интеграций может быть несколько в обе стороны. Например, через одну интеграцию с 1С на сайт выгружаются товары, а через вторую с сайта в 1С — новые заказы, через третью на сайт из 1С приходят обновленные статусы заказов, через четвертую… Продолжать можно бесконечно.

ETL и хранилище в такой интеграции находятся внутри самих систем. Система-источник извлекает из своих баз информацию и преобразует её в удобный для потребления вид. Система-получатель сохраняет информацию для последующей обработки. Никаких посредников, дополнительных хранилищ или общего контекста.

Плюсы подхода «точка — точка»

1. Самый быстрый в смысле разработки тип интеграции: достаточно коробочных API и небольших доработок. Об их логике использования договариваются команды разработки разных сервисов.
2. Настраивается такая интеграция быстро, особенно при небольшом количестве сервисов внутри контура.
3. Создание прямой интеграции с простой логикой — недорогая задача.

Минусы подхода «точка–точка»

Минусов в такой интеграции больше.

• Сильная взаимозависимость систем. Например, чтобы пользователь оформил заказ, интернет-магазин должен получить от 1С информацию о статусе в программе лояльности и адресе пользователя. Стоит 1С «упасть» или замедлиться из-за высокой нагрузки — и критичная информация перестанет поступать в интернет-магазин. Покупатели не смогут оформлять заказы, пока 1С не восстановится.

Чтобы обезопасить бизнес от таких рисков, команда разработки будет постоянно изобретать предохранители: расставлять флаги, придумывать очереди, переизобретать асинхронную отправку сообщений между системами. Но тогда относительно низкую стоимость такой интеграции в какой-то момент можно будет убрать из списка плюсов.

• Один сервис «знает» контекст другого сервиса. В каком формате и с какой скоростью нужно отдавать данные, какие данные избыточны или недостаточны? Когда общего контекста нет, сервисам приходится «додумывать» самим.
• Интеграции перегружают систему-источник. Это замедляет скорость ответа системы и приводит к ошибкам в данных. В случае с большим количеством интеграций такой подход делает ИТ-контур непрозрачным и неповоротливым. С подобной проблемой к нам пришел один из клиентов→ – компания с более 200 розничными торговыми точками, каждая из которых была интегрировала с системой головного офиса по принципу «точка-точка».
• Изменение в любой системе запускает каскад доработок во всех связанных интеграциях и системах. Причем они могут быть минимальными: добавление даже одного нового параметра в карточку товара повлечет за собой изменение логики во всех системах, которые забирают эту карточку.
• С таким подходом к интеграции компаниям сложно масштабироваться. Этот пункт – следствие всех проблем выше. Показательный пример – кейс нашего клиента→, команды приложения для таксопарков и автопарков, которое автоматизирует получение путевых листов. Прямое соединение работало адекватно, пока к системе были подключены всего три автопарка с одной базой данных на каждый. Но когда их количество выросло, ресурсов системы стало явно недостаточно.

Что по связанности?

Легкость и скорость доработки интеграций/сервисов:

• Не соответствует. Изменение в одной системе требует изменений в связанных системах, что усложняет и замедляет доработки.

Выдерживание пиковых нагрузок и работа без задержек:

• Частично соответствует. Изначально интеграции работают быстро, но при увеличении количества запросов система-источник может перегружаться, что приводит к задержкам.

Запуск нового потока данных без доработки сервисов:

• Не соответствует. Запуск новых потоков данных требует изменений в каждой из интегрируемых систем.

Отсутствие проблем в других сервисах при ошибке в одном:

• Не соответствует. Ошибка в одной системе может вызвать проблемы в других, поскольку они тесно взаимосвязаны.

Легкость мониторинга и возможность делегирования техподдержке:

• Не соответствует. Мониторинг сложен из-за высокой взаимосвязанности систем, требующей участия команды разработки.

Итог: 0,5 баллов слабой связанности из 5.

Если монолиты с сильной связанностью — не ваша цель, интеграций «точка-точка» лучше избегать.

Интеграция через брокер

В такой интеграции помимо системы-источника и системы-получателя появляется промежуточный слой — брокер сообщений. Системы не взаимодействуют друг с другом — только с Apache Kafka, RabbitMQ или любым аналогичным сервисом. При этом инициаторами отправки и получения информации по-прежнему остаются IT-системы.

В этом типе интеграции хранилище информации выведено за пределы конечных систем: если информация уже попала в брокер, то система-получатель заберёт её оттуда в условленное время. ETL-логика всё ещё остаётся на стороне систем-участниц интеграции: ответственность за извлечение, преобразование и загрузку распределена между системой-источником и системой-получателем.

Плюсы интеграции через брокер

1. Обмен данными становится более контролируемым. В брокере можно посмотреть, какие сообщения были отданы, какие доставлены, посмотреть логи, увидеть ретроспективу по событиям.
2. Системам-источникам не надо выяснять, доступна ли система-получатель в момент отправки сообщения. В их зоне ответственности — только логика формирования собственной очереди сообщений.
3. Брокеры сообщений обычно поддерживают контракты, то есть проверяют сообщения на базовые правила (например, наличие определенного поля в нужном формате).
4. Такая интеграция делает разработку более стандартизированной. Почти в каждом сервисе есть инструменты для подключения брокера. А значит, не нужно заниматься разработкой с нуля, придумывать костыли и изобретать логику интеграций каждый раз не приходится.
5. Брокер как и «точка-точка» поддерживает высокую скорость передачи данных между сервисами.

Минусы интеграции через брокер

1. Брокер перегружает систему-источник лишними действиями. Если брокер некоторое время был недоступен, то в этот период никакие новые сообщения в очередь не добавлялись. Сам брокер «не знает», что и какая система пыталась в него отправить. Соответственно, системе-источнику приходится проверять, какое сообщение было последним в очереди, и повторно отправить всё, что накопилось за время недоступности.
2. Брокер перегружает систему-получателя лишними данными. Брокер не может выбрать, какие сообщения передавать, он отдаёт всю очередь. Например, всю информацию по ассортименту или данные из WMS по остаткам на складах, даже если их большая часть не нужна системе-получателю. Но последняя все равно сохраняет их свои базы данных и за счет внутренней логики отделяет 5% нужных данных от 95% лишних.
3. Использование брокера приводит к «цементированию» контракта. Все участники процесса должны договориться о том, в каком формате будет передаваться сообщение. Это лишает гибкости и приводит к росту трудозатрат на поддержку единого формата.
4. Еще один минус — отсутствие удобной и/или детальной ретроспективы. Например, брокер Kafka может хранить исторические данные — но если что-то сломается, придется прогружать всю очередь сообщений от исторически первой до последней записи. Никаких выборок по актуальным статусам сделать невозможно. Проблема стоит наиболее остро в тех случаях, когда нужно обменяться историей с другой командой или осуществить миграцию.
5. Более медленное чтение данных. С одной стороны, системы быстро обмениваются всем потоком сообщений, но с другой — разобраться, что актуально, исключить дубликаты — сложно.
6. Есть и неочевидный минус управленческого толка. У каждой системы есть свой продакт-оунер, а владельцем брокера чаще всего становится технический отдел. Для остальных подразделений — это плюс (меньше ответственности), но в итоге ни у кого из заинтересованных подразделений нет ощущения контроля за инфраструктурой.

Что по связанности?

Легкость и скорость доработки интеграций/сервисов:

• Частично соответствует. Обмен данными стандартизирован, но необходимость поддержания единого формата данных может ограничить гибкость.

Выдерживание пиковых нагрузок и работа без задержек:

• Частично соответствует. Интеграция поддерживает высокую скорость передачи данных, но возможна перегрузка системы-источника из-за избыточных действий и данных.

Запуск нового потока данных без доработки сервисов:

• Не соответствует. Новый поток данных требует проверки и возможно доработок для соответствия контрактам брокера.

Отсутствие проблем в других сервисах при ошибке в одном:

• Частично соответствует. Система-источник не зависима от доступности системы-получателя, но перегрузка брокера может вызвать задержки.

Легкость мониторинга и возможность делегирования техподдержке:

• Частично соответствует. Брокер позволяет мониторить данные и логи, но сложность ретроспективы и детализации событий может затруднять полное делегирование техподдержке.

Итого: 2 балла слабой связанности из 5.

Интеграция с помощью шины (ESB)

ESB — практический инструмент реализации интеграций в слабо связанной архитектуре.

В интеграцию через ESB-слой входят:

• Системы — источники и потребители.
• Отдельный слой ETL-микросервисов, которые забирают и отдают данные, трансформируют и нормализуют информацию. Формат данных, скорость передачи, частота обновлений – вся эта логика находится здесь.
• Отдельный контур хранилищ. Может быть реализован по-разному: некоторые шины поддерживают opensource-решения типа PostgreSQL или MySQL, другие используют внутреннее хранилище.

Все три составляющих разделены и выполняют свою функцию: система генерирует и потребляет данные, ETL-слой передаёт по назначению и в нужном виде, хранилища (что логично) хранят данные.

Плюсы использования шины

1. Нагрузка на каждую систему становится контролируемой. Задача сервиса — предоставить доступ к данным по API (если речь идет о современном сервисе), FTP или любым другим доступным способом. ETL-слой сам заберёт данные и передаст дальше, в хранилище. Сервис «думает» лишь о том, чтобы вся информация, за которую он отвечает, была актуальной и полной в момент передачи.
2. Можно быстро подключать в контур любые системы или дорабатывать их в произвольном порядке. Этот аспект – главное условие эффективной масштабируемости бизнеса. Вот пример, как мы решали проблему масштабируемости с помощью внедрения ESB-слоя в компании-производителе электрооборудования и комплексных энергоэффективных решений.
3. Шина берет на себя фильтрацию информации. ESB отправляет сервису только те данные, которые ему реально нужны — достаточно заложить такую логику в коннектор.
4. Интеграции унифицированы, логика сервисов становится проще. ETL-слой использует типовую логику на получение и отправку данных. Разработка новых коннекторов сводится к воспроизводству уже разработанной логики с поправками на конкретный тип данных или особенности системы.
5. Разработку и мониторинг можно делегировать. Этот плюс вытекает из предыдущего. Разработка упрощается, а обязанности по мониторингу можно снять с разработчиков и делегировать техподдержке.
6. Правильная интеграция через ESB предполагает отказоустойчивость всей IT-архитектуры. Сервисы обмениваются данными не напрямую: ETL-слой сохраняет их в специальные хранилища и по необходимости забирает актуальную версию оттуда же.

Минусы использования шины

Глобально, их два:

1. Трудоёмкость на старте. Для правильных интеграций нужно проанализировать IT-архитектуру: выделить зоны ответственности и определить нужную и избыточную информацию. В среднем, внедрение ESB-слоя занимает 15-20 месяцев до запуска MVP.
2. Довольно высокая стартовая стоимость. Уже на старте придется заплатить и за бизнес-анализ, и за продумывание логики интеграции, и за внедрение инструментов шины — ETL-слоя, DWH и т. д. Тут подробно расписали затраты на внедрение ESB-слоя на каждом этапе.

Что по связанности?

Легкость и скорость доработки интеграций/сервисов:

• Соответствует. Сервисы можно легко дорабатывать или подключать новые, благодаря разделению ETL-слоя и хранилища данных.

Выдерживание пиковых нагрузок и работа без задержек:

• Соответствует. ESB позволяет контролировать нагрузку на каждую систему, обеспечивая стабильную работу при пиковых нагрузках.

Запуск нового потока данных без доработки сервисов:

• Соответствует. Новый поток данных можно запустить без доработок сервисов, поскольку логика передачи данных управляется в ETL-слое.

Отсутствие проблем в других сервисах при ошибке в одном:

• Соответствует. Ошибка в одном сервисе не влияет на другие благодаря изоляции данных в ETL-слое и хранилище.

Легкость мониторинга и возможность делегирования техподдержке:

• Соответствует. Мониторинг интеграций можно делегировать техподдержке, так как ESB предоставляет необходимые инструменты для наблюдения и управления.

Итого: 5 баллов слабой связанности из 5.

Важно: выбор правильного инструмента интеграции — не волшебная таблетка от монолита

Часто считают, что внедрение брокера или ESB решит все проблемы IT-контура. Но это не так. Невозможно построить правильную архитектуру, не расшивая зоны ответственности и не избавляясь от связанности.

Даже после внедрения шины архитектура может остаться монолитной, если неправильно поделены границы сервисов или логика ETL-коннекторов переусложнена. Как резхультат — команда бесконечно генерит код вместо того, чтобы делать интеграции просто и понятно. Вместо слабой связанности и отказоустойчивости на выходе получается трудно поддерживаемая архитектура.

Непонимание подхода или отсутствие опыта в работе с ESB может привести к тому, что ответственный за внедрение может неправильно построить интеграцию — например, переложив на промежуточный слой лишнюю бизнес-логику. Это отразится и на скорости разработки в моменте, и на стоимости дальнейших доработок.

Чтобы до этого не дошло, нужна компетентная команда внедрения: порог входа здесь выше, чем в интеграциях «точка–точка».

‍